Invoicing system

ABSTRACT

A method to facilitate invoicing for transactions established utilizing a network-based transaction system includes supporting establishment of transactions between a plurality of entities in the network-based transaction system, and identifying as part of an invoice generation process, a plurality of transactions to which a first entity is a party. The method further includes identifying first and second transactions from the plurality of transactions that satisfy combinable criteria, and generating an invoice for at least the first and second transactions that satisfy the combinable criteria. The method can also be implemented in a system and on a machine-readable medium.

RELATED APPLICATIONS

This application is a divisional of U.S. application Ser. No. 10/882,633filed Jun. 30, 2004, which claimed the benefit of U.S. ProvisionalApplication Nos. 60/495,608, filed Aug. 14, 2003 and 60/501,251, filedSep. 8, 2003, all of which are incorporated herein by reference in theirentirety.

TECHNICAL FIELD

The present invention relates generally to the technical field ofcommerce automation and, in particular, to methods and systems tofacilitate generation of invoices combining multiple transactionsestablished utilizing a network-based transaction system, and inparticular, a multi-seller network-based marketplace.

BACKGROUND

Network-based marketplaces have, with the widespread adoption ofInternet technologies, become increasingly popular venues for the buyingand selling of goods and services. As more and more sellers turn tonetwork-based marketplaces as an important distribution channel, theneed to provide invoicing tools to such sellers has increased.

While a number of traditional invoicing tools (e.g., Quickbooks,developed and distributed by Intuit, Inc.) are typically available tosellers, such invoicing tools are typically independent of a marketplaceat which a seller may have established transactions. Accordingly, theseller is required manually to input information relating totransactions for which invoices are to be generated.

In order to make a network-based marketplace more attractive to sellers,there is some incentive for an operator of the network-based marketplaceto provide invoicing tools that are tightly integrated with themarketplace, and that can automatically retrieve and include informationregarding transactions within invoices. However, the design of suchintegrated invoicing tools presents a number of technical challenges,specifically regarding how the invoices may be customized to accommodatethe unique requirements of a particular transaction and of a particularbuyer or seller. Further, a number of technical challenges exist withrespect to the automation of invoice generation by such invoicing tools,given the large number of the variables that may be associated with aparticular transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying drawings, in which likereferences indicate similar elements and in which:

FIG. 1 is a network diagram depicting a commerce system, according toone exemplary embodiment of the present invention.

FIG. 2 is a block diagram illustrating multiple market applicationsprovided as part of a network-based marketplace, according to oneembodiment of the present invention.

FIG. 3 is a high-level entity-relationship diagram, illustrating variousdatabases that may be utilized by and support the marketplace.

FIG. 4 shows various fields of database tables.

FIG. 5 is a flow diagram of one embodiment of a process for creatinginvoices combining multiple transactions established utilizing anetwork-based marketplace.

FIGS. 6 and 14 are block diagrams of two alternative embodiments of aseller-initiated process for generating invoices consolidating multipleitems.

FIG. 19 is a block diagram of one embodiment of a buyer-initiatedprocess for generating invoices consolidating multiple items.

FIGS. 29A-29B and 30A-30C are block diagrams of several embodiments of aprocess for defining rules for charges associated with combinedtransactions.

FIGS. 35 and 37 are block diagrams of two embodiments of a process forcalculating charges for invoices including combined transactions usingpredefined charge rules.

FIGS. 7-13, 15-18, 20-28, 31-34 and 36 illustrate exemplary userinterfaces (UIs) presented to a user of the marketplace, according tovarious embodiments of the present invention.

FIG. 38 is a diagrammatic representation of an exemplary computersystem.

DETAILED DESCRIPTION

A method and system to facilitate generation of invoices combiningmultiple transactions, established utilizing a multi-sellernetwork-based marketplace, are described. In the following description,for purposes of explanation, numerous specific details are set forth inorder to provide a thorough understanding of the present invention. Itwill be evident, however, to one skilled in the art that the presentinvention may be practiced without these specific details.

Platform Architecture

FIG. 1 is a network diagram depicting a commerce system 10, according toone exemplary embodiment of the present invention, having aclient-server architecture. Specifically, a trading platform, in theexemplary form of a network-based marketplace 12, provides server-sidefunctionality, via a network 14 (e.g., the Internet) to one or moreclients. FIG. 1 illustrates, for example, a web client 16 (e.g., abrowser, such as the Internet Explorer browser developed by MicrosoftCorporation of Redmond, Wash. State), and a programmatic client 18executing on respective client machines 20 and 22.

Turning specifically to the network-based marketplace 12, an ApplicationProgram Interface (API) server 24 and a web server 26 are coupled to,and provide programmatic and web interfaces respectively to, one or moreapplication servers 28. The application servers 28 host one or moremarketplace applications 30 and payment applications 32. In oneembodiment, the application servers 28 include a marketplace serverhosting one or more marketplace applications 30 and a payment serverhosting one or more payment applications 32.

The application servers 28 are coupled to one or more databases servers34 that facilitate access to one or more databases 36.

The marketplace applications 30 support a number of marketplacefunctions and services to clients that access the marketplace 12. Thepayment applications 32 likewise provide a number of payment servicesand functions to clients that access marketplace 12. While themarketplace and payment applications 30 and 32 are shown in FIG. 1 toboth form part of the network-based marketplace 12, it will beappreciated that in alternative embodiments of the present invention,the payment applications 32 may form part of a payment service that isseparate and distinct from the marketplace 12.

Further, while the commerce system 10 shown in FIG. 1 employs aclient-server architecture, the present invention is of course notlimited to such an architecture, and could equally well find applicationin a distributed, or peer-to-peer, architecture system. The variousmarketplace and payment applications 30 and 32 could also be implementedas standalone software programs, which do not necessarily havenetworking capabilities.

The web client 16, it will be appreciated, accesses the variousmarketplace and payment applications 30 and 32 via the web interfacesupported by the web server 26. Similarly, the programmatic client 18accesses the various services and functions provided by the marketplaceand payment applications 30 and 32 via the programmatic interfaceprovided by the API server 24. The programmatic client 18 may, forexample, be a seller application (e.g., the TurboLister applicationdeveloped by eBay Inc., of San Jose, Calif.) to enable sellers to authorand manage listings on the marketplace 12 in an off-line manner, and toperform batch-mode communications between the programmatic client 18 andthe network-based marketplace 12.

FIG. 1 also illustrates a third party application 38, executing on athird party server machine 40, as having programmatic access to thenetwork-based marketplace 12 via a programmatic interface 40 and theprogrammatic interface provided by the API server 24. For example, thethird party application 38 may, utilizing information retrieved from thenetwork-based marketplace 12, support one or more features or functionson a website hosted by the third party. The third party website may, forexample, provide one or more marketplace or payment functions that aresupported by the relevant applications of the network-based marketplace12.

Marketplace Applications

FIG. 2 is a block diagram illustrating multiple market applications 30that, in one exemplary embodiment of the present invention, are providedas part of the network-based marketplace 12. The marketplace 12 mayprovide a number of listing and price-setting mechanisms whereby aseller can list goods or services for sale, a buyer can express interestin or indicate a desire to purchase such goods or services, and a pricecan be set for a transaction pertaining to the goods or services. Tothis end, the marketplace applications 30 are shown to include one ormore auction applications 44 with support auction-format listings andprice setting mechanisms (e.g., English, Dutch, Vickrey, Chinese,Double, Reverse auctions etc.). The various auction applications 44 mayalso provide a number of features in support of such auction-formatlistings, such as a reserve price feature whereby a seller may specify areserve price in connection with a listing and a proxy-bidding featurewhereby a bidder may invoke automated proxy bidding.

A number of fixed-price applications 46 support fixed-price listingformats (e.g., the traditional classified advertisement-type listing ora catalogue listing) and buyout-type listings. Specifically, buyout-typelistings may be offered in conjunction with an auction-format listing,and allow a buyer to purchase goods or services, which are also beingoffered for sale via an auction, for a fixed-price which is typicallyhigher than the starting price of the auction.

Store applications 48 allow sellers to group their listings within a“virtual” store, which may be branded and otherwise personalized by andfor the sellers. Such a virtual store may also offer promotions,incentives and features that are specific and personalized to a relevantseller.

Reputation applications 50 allow parties that transact utilizing thenetwork-based marketplace 12 to establish, build and maintainreputations which may be made available and published to potentialtrading partners. Specifically, where the network-based marketplace 12supports person-to-person trading, parties to a transaction may have nohistory or other reference information whereby trustworthiness andcredibility may be ascertained. The reputation applications 50 allow aparty, for example through feedback provided by other transactionpartners, to establish a reputation over time within the network-basedmarketplace 12. Other potential trading partners may then reference sucha reputation for the purposes of assessing credibility andtrustworthiness.

Personalization applications 52 allow users of the marketplace 12 topersonalize various aspects of their interactions with the marketplace12. For example a user may, utilizing an appropriate personalizationapplication 52, create a personalized reference page at whichinformation regarding transactions to which the user has been a partymay be viewed. Further, a personalization application 52 may enable auser to personalize listings and other aspects of their interactionswith the marketplace 12 and other parties.

In one embodiment, the network-based marketplace 12 may support a numberof marketplaces that are customized, for example, for specificgeographic regions. A version of the marketplace 12 may be customizedfor the United Kingdom, whereas another version of the marketplace 12may be customized for the United States. Each of these versions mayoperate as an independent marketplace, or may be customized (orinternationalized) presentations of a common underlying marketplace.

Navigation of the network based-marketplace 12 may be facilitated by oneor more search applications 56. For example, a search applicationenables key word searches of listings published via the marketplace 12.A browse application allows users to browse various category, orcatalogue, data structures according to which listings may be classifiedwithin the marketplace 12. Various other navigation applications may beprovided to supplement the search and browsing applications.

In order to make listings available via the network-based marketplace 12as visually informing and attractive as possible, the marketplaceapplications 30 may include one or more imaging applications 58utilizing which users may upload images for inclusion within listings.An imaging application 58 also operates to incorporate images withinviewed listings. The imaging applications 58 may also support one ormore promotional features, such as image galleries that may be presentedto potential buyers. For example, sellers may pay an additional fee tohave an image associated with one or more of the listings includedwithin a gallery of images for promoted items.

Listing creation applications 60 allow sellers conveniently to authorlistings pertaining to goods or services that they wish to transact viathe marketplace 12, and listing management applications 62 allow sellersto manage such listings. Specifically, where a particular seller hasauthored and/or published a large number of listings, the management ofsuch listings may present a challenge. The listing managementapplications 62 provide a number of features (e.g., auto-relisting,inventory level monitors, etc.) to assist the seller in managing suchlistings. One or more post-listing management applications 64 alsoassist sellers with a number of activities that typically occurpost-listing. For example, upon completion of an auction facilitated byone or more auction applications 44, a seller may wish to leave feedbackregarding a particular buyer. To this end, a post-listing managementapplication 64 may provide an interface to one or more reputationapplications 50 so as to allow the seller conveniently to providefeedback regarding multiple buyers to the reputation applications 50.

Dispute resolution applications 66 provide mechanisms whereby disputesthat may arise between transacting parties may be resolved.Specifically, the dispute resolution applications 66 may provide guidedprocedures whereby the parties are guided through a number of steps inan attempt to settle the dispute. In the event that the dispute cannotbe settled via the guided procedures, the dispute may be escalated to athird party mediator or arbitrator.

A number of fraud prevention applications 68 implement various frauddetection and prevention mechanisms to reduce the occurrence of fraudwithin the marketplace 12.

Messaging applications 78 are responsible for the generation anddelivery of messages to users of the network-based marketplace 12, suchmessages for example advising users regarding the status of listings atthe marketplace 12 (e.g., providing “outbid” notices to bidders duringan auction process or to provide promotional and merchandisinginformation to users).

Merchandising applications 80 support various merchandising functionsthat are made available to sellers to enable sellers to increase salesvia the marketplace 12. The merchandising applications 80 also operatethe various merchandising features that may be invoked by sellers, andmay monitor and track the success of merchandising strategies employedby sellers.

The network-based marketplace 12 itself, or one or more parties thattransact via the marketplace 12, may operate loyalty programs that aresupported by one or more loyalty applications 82. For example, a buyermay earn loyalty points for each transaction established and/orconcluded with a particular seller, and be offered a reward for whichaccumulated loyalty points can be redeemed.

So as to enable sellers effectively to generate and communicate invoicesto buyers, the marketplace applications 30 include one or more invoiceapplications 84. According to one exemplary embodiment of the presentapplication, the invoice applications 84 may include an orderapplication 86 that allows a user of the network-based marketplace 12(e.g., a buyer or a seller) conveniently to combine multipletransactions into a single order for invoicing purposes. The invoicingapplications 84 may also include a shipping and handling chargeapplication 84 to at least partially automate the calculation ofshipping and handling charges in connection with one or more orders, andan insurance charge application 86 to at least partially automate thecalculation of insurance charges in connection with an order. The orderapplication 86 is shown to include an order discount module 88, whichautomatically calculates and applies discounts in connection withvarious order conditions, and according to stored rules. Similarly, theshipping application 84 is shown to include a shipping discount module90, which operates automatically to calculate and apply shippingdiscounts according to stored rules. Further details regarding theexemplary embodiments of the invoice applications 84 are provided below.

Data Structures

FIG. 3 is a high-level entity-relationship diagram, illustrating varioustables 91 that may be maintained within the databases 36, and that areutilized by and support the marketplace 12 and payments applications 30and 32. A user table 92 contains a record for each registered user ofthe network-based marketplace 12, and may include identifier, addressand financial instrument information pertaining to each such registereduser. A user may, it will be appreciated, operate as a seller, a buyer,or both, within the network-based marketplace 12.

The tables 91 also include an items table 94 in which is maintained anitem record for each item or service that is available to be, or hasbeen, transacted via the marketplace 12. Each item record within theitems table 94 may furthermore be linked to one or more user recordswithin the user table 92, so as to associate a seller and one or moreactual or potential buyers with each item record.

FIG. 4 shows various fields that may be supported for each record withinthe items table 94. Particularly pertinent to the exemplary embodimentof the present invention, it will be noted that each item record mayinclude a “combinable” field 96, which may record an indication,provided by a seller, that a transaction pertaining to the relevant itemis combinable with other transactions for the purposes of a creating asingle order. Trade status, invoice status, payment status and currencyidentifier fields 98-104 may also be utilized by an invoice application84, as described below, in the generation of an invoice pertaining to anorder.

Referring to FIG. 3, the tables 91 also include a transaction table 106,which contains a record for each transaction (e.g., a purchasetransaction) pertaining to items for which records exist within theitems table 94. Specifically, a transaction record in connection with aparticular item may be created in the transaction table 106 upon theestablishment of an agreement between a buyer and seller to exchangevalue in connection with a particular good or service.

As illustrated in FIG. 4, each record within the transaction table 106may include an item identifier 108 that links to an item record withinthe items table 94, a seller identifier 110 and a buyer identifier 112,each of the seller and buyer identifiers 110 and 112 linking to a userrecord within the user table 92. It should be noted that multipletransaction records within the transaction table 106 might link back toa single item record within the items table 94, where that single itemrecord relates to a multi-quantity item.

An order table 114 is populated with order records, each order recordbeing associated with an order. Each order, in turn, may be with respectto one or more transactions for which records exist within thetransactions table 106. As such, a particular order record within theorder table 114 may reference multiple transaction identifiers 116. Inthe exemplary embodiment, each order record may indicate only a singlebuyer-seller pairing, this buyer-seller pairing being identified by theseller and buyer identifiers 110 and 112.

The tables 91 are also shown to include a rules table 118, which isshown to be linked to the user table 92. Specifically, the rules table118 is populated with rule records, each rule record identifying variouscharge rules that are associated with users of the network-basedmarketplace 12. Referring specifically to FIG. 4, it will be noted thateach rules record includes seller identifier and buyer identifier fields110 and 112. Accordingly, a particular rule may be associated with auser in the role of a buyer or a seller. For example, a particularcharge rule may be associated with a particular user when that useroperates in a buyer role at the marketplace 12, and a different chargerule may be associated with the particular user when that user operatesin a seller role at the marketplace 12.

Each rule record within the rules table 118 may also record a purchasecharge rule 120, a shipping and handling charge rule 122, and a shippinginsurance charge rule 124. An invoice application 84 references therules 120-124 when calculating total charges for an order, to bereflected in an invoice. Accordingly, the rules 120-124 allow a user'spreferences to be reflected in the automated (or at least partiallyautomated) calculation of total charges in connection with an order.Specifically, a purchase charge rule 120 may specify a chargecalculation rule to be invoked with respect to purchases involving anidentified user. For example, a user, when acting in the capacity of aseller, may specify a purchase charge rule 120 in terms of which adiscount (e.g., a percentage off a total purchase price) is offered whena buyer purchases multiple items. Similarly, a shipping and handlingcharge rule 122 may specify how shipping and handling charges arecalculated with respect to items purchased from the user, when acting inthe capacity of a seller. In one exemplary embodiment of presentinvention, such shipping and handling charge rules 122 include actualrate shipping charge rules and flat rate shipping charge rules, eachrule type being customizable by a seller to reflect the seller'spreferences. Further details regarding exemplary shipping and handlingcharge rules 122 are provided below. A shipping insurance charge rule124 similarly reflects user preferences with respect to the calculationof shipping insurance charges, and may be invoked by an invoiceapplication 84 to at least partially automate the calculation of suchcharges when generating an invoice.

FIG. 3 also illustrates the tables 91 as including a bids table 130.Each bid record within the bids table 130 relates to a bid received atthe network-based marketplace 12 in connection with an auction form oflisting supported by an auction application 44. A feedback table 132 isutilized by one or more reputation applications 50, in one exemplaryembodiment, to construct and maintain reputation information concerningusers. A history table 134 maintains a history of transactions to whicha user has been a party. One or more attributes tables 136 recordattribute information pertaining to items for which records exist withinthe items table 94. Considering only a single example of such anattribute, the attributes tables 136 may indicate a currency attributeassociated with a particular item.

Invoices Combining Multiple Transactions

FIG. 5 is a flow diagram of one embodiment of a process 500 for creatinginvoices combining multiple transactions established utilizing anetwork-based marketplace. Process 500 may be performed by processinglogic, which may comprise hardware, software, or a combination of both.In one embodiment, processing logic resides in a payment server (e.g.,one of the application servers 28 of FIG. 1).

Referring to FIG. 5, process 500 begins with processing logic locatingconcluded transactions involving a first user in a predefined timeperiod (processing block 502). A transaction is concluded when anagreement is established between two parties (e.g., a buyer and aseller) to exchange value in connection with an item (e.g., a good or aservice) or multiple quantities of an item. The first user may representeither of the two parties. A predefined time period may besystematically defined or specified by the first user. In oneembodiment, processing logic locates concluded transactions by searchinga transaction table 106 of FIG. 3.

At processing block 504, processing logic identifies concludedtransactions that satisfy combinable criteria. The combinable criteriamay require, for example, that the transactions be from a common buyerand a common seller, be unpaid, be associated with the same currencyand/or the same marketplace site (a marketplace customized for the samegeographic region), etc. The combinable criteria may be configurablebased on a specific marketplace or a marketplace site.

At processing block 506, processing logic identifies the combinabletransactions to the first user. For example, processing logic mayidentify the combinable transactions by displaying them to the firstuser with a combinability indicator (e.g., an icon), providing a link toa screen displaying each or all subsets of the identified combinabletransactions, requesting the first user to specify his or her tradingpartner and displaying all combinable transactions between the firstuser and the trading partner, etc.

At processing block 508, processing logic receives data indicating thefirst user's approval for consolidating a subset of combinabletransactions into a single order. For example, processing logic mayreceive the data indicating the first user's approval when the firstuser selects two or more transactions from a displayed subset ofcombinable transactions and clicks a designated button (e.g., a sendinvoice button or a combine items button, a pay now button, etc.) on thescreen. In another embodiment, the invoice may include multiple subsetsof combinable transactions associated with the first user and differenttrading partners of the first user. In yet another embodiment, theinvoice may include one or more subsets of combinable transactions andone or more individual transactions associated with the first user anddifferent trading partners of the first user.

At processing block 510, processing logic adds charges to the order withcombined transactions. The charges may include, for example, shippingcosts, shipping insurance costs, etc. The charges may include a discountfor consolidating combinable transactions into a single order. In oneembodiment, the charges are applied based on rules specified by theseller. In another embodiment, the charges are applied based on rulesestablished in the network-based marketplace. In yet another embodiment,the charges are applied based on input provided by the first user forthe current order. In still another embodiment, the charges are appliedbased on input provided by the trading partner for the current order inresponse to the first user's request for this input.

Next, processing logic creates a preview invoice for the order, presentsthe preview invoice to the first user (processing block 512), and asksthe first user to approve the preview invoice. If the first userapproves the invoice (decision box 514), processing logic saves theinvoice (processing block 516) and, in one embodiment, notifies thetrading partner about the invoice. If the first user does not approvethe invoice, processing logic cancels the invoice for the order(processing block 516) and, in one embodiment, creates an individualinvoice for each transaction in the order.

In one embodiment, an order combining multiple transactions may becreated either by a seller or a buyer. In one embodiment, an order has aspecific state. For example, an order may be active, inactive, complete,or cancelled. An active order is the most recent order created by eitherthe buyer or seller. A transaction may only be part of a single activeorder at any given time. An inactive order is an order that becameinactive because either (a) the seller has uncombined a seller createdactive order, (b) the buyer has uncombined a seller created activeorder, or (c) the buyer has created a new order replacing a previousbuyer created active order. A complete order is an order paid by thebuyer (e.g., when the buyer completes checkout or pays through anelectronic payment service on an active or inactive order). An order iscancelled when any of its transactions no longer satisfy the combinablecriteria. For example, an order containing an item for which the buyerhas made a payment is marked as cancelled.

In one embodiment, a buyer is allowed to create an order with combinabletransactions that are not part of an existing active seller-createdorder or a complete order. If the buyer creates an order that consistsof transactions from an existing active buyer-created order, thisexisting order is marked as inactive. The transactions may only beassociated with a single active order. A seller is allowed to create anorder with combinable transactions that are not part of a completeorder. If the seller creates an order with combinable transactions thatare part of an existing active buyer-created order, this buyer-createdorder is marked as inactive, and its transactions are associated to thenew active seller-created order.

In one embodiment, a buyer can pay for any order that is not marked ascomplete. Any active or inactive order may be checked out or paidthrough the electronic payment service by the buyer. If the buyercompletes checkout or pays through the electronic payment service on anactive order, the status of the order is marked as completed. If thebuyer completes checkout or pays through the electronic payment serviceon an inactive order, the status of the inactive order is marked ascompleted. For example, if the buyer first creates the order andproceeds to pay at the electronic payment service, and then the sellercreates an order with the same items prior to the buyer completing thepayment, the buyer-created order is marked as inactive, and thetransactions are associated to the active seller-created order.

In one embodiment, each order is referenced by a unique sales recordnumber associated with a seller.

FIGS. 6 and 14 are block diagrams of two alternative embodiments of aseller-initiated process for generating invoices consolidating multipleitems. The process may be performed by processing logic, which maycomprise hardware, software, or a combination of both.

Referring to FIG. 6, process 600 will be described in conjunction withexemplary user interfaces illustrated in FIGS. 7-13. In one embodiment,processing logic of process 600 resides in a payment server (e.g., oneof the application servers 28 of FIG. 1).

Process 600 may start with any one of processing blocks 602, 604 and606. At processing block 602, processing logic receives data identifyinga seller's selection of a buyer for whom the invoice should begenerated. In one embodiment, processing logic identifies subsets ofitems purchased from the seller that can be combined based on thecombinability criteria, presents to the seller a user interface (UI)that displays a list of buyers who purchased combinable items from theseller, and allows the seller to select a specific buyer. Whenprocessing logic receives the seller's selection of the specific buyer,it proceeds to processing block 608 where a list of items purchased fromthe seller by the selected buyer is displayed. FIG. 7 illustrates anexemplary UI (Select a Buyer to Invoice UI) that allows a seller tospecify a buyer for whom the invoice should be generated.

At processing block 604, processing logic receives the seller'sselection of a combinability indicator associated with an item purchasedfrom the seller. In one embodiment, processing logic identifies subsetsof items purchased from the seller that can be combined based on thecombinability criteria, displays a list of items purchased from theseller within a certain time period (e.g., as specified by the seller)with each combinable item having a combinability indicator (e.g., adesignated icon), and allows the seller to select a combinabilityindicator of a specific item. When processing logic receives theseller's selection of a combinability indicator of a specific item, itproceeds to processing block 608 where a list of items that can becombined with the specific item is displayed. FIG. 8 illustrates anexemplary UI (Items I've Sold UI) that presents each combinable itemwith an icon and allows a seller to select an icon of a specific item toview the items combinable with the specific item.

At processing block 606, processing logic receives the seller's requestto add other items to the invoice being created. In one embodiment,processing logic identifies items that can be combined, based on thecombinability criteria, with the item for which the invoice is beingcreated, and provides on the invoice page a link to a list of items thatcan be combined with the item on the invoice. When processing logicreceives the seller's selection of the link, it proceeds to processingblock 608 where a list of items that can be combined with the item onthe invoice is displayed. FIG. 9 illustrates an exemplary UI (SendInvoice UI) that includes a link to a list of items combinable with thedisplayed item.

At processing block 608, processing logic displays a list of combinableitems and allows the seller to modify this list (e.g., by removing someitems from the list). At processing block 610, processing logic receivesthe seller's input regarding the displayed items and, in one embodiment,allows the seller to specify charges for the items (e.g., shipping andhandling charges, shipping insurance, etc.). In another embodiment,processing logic calculates charges for the items based on rulesspecified by the seller or standard rules maintained within themarketplace. FIGS. 10A and 10B illustrate exemplary ins (CombinePurchases UI and Send Invoice UI) that allow the seller to check itemsto be combined in the invoice, specify charges (shipping and handlingcharges, shipping insurance, and sales tax) for the combined items,enter payment instructions for the buyer, and specify payment methodsacceptable to the seller.

Next, upon receiving the seller's request to combine the specified items(e.g., via the Combine Purchase UI) (processing block 612), processinglogic ensures that the items are still combinable (i.e., satisfy thecombinable criteria) (processing block 613), and saves the resultingorder in a database (processing block 614). One or more items may nolonger satisfy the combinable criteria if, for example, the buyer haspaid or completed the checkout on the items during the seller'sinteraction with the UI, or the seller has created another active ordercontaining the items using a different browser window. Then, processinglogic removes the items that no longer satisfy the combinable criteriafrom the order and asks the seller to review the remaining items.

The order saved in the database is subsequently retrieved from thedatabase in response to the seller's request to send the invoice for theorder to the buyer.

Alternatively, processing logic may receive the seller's request to sendthe invoice when receiving the seller's input regarding the displayeditems and the applicable charges (e.g., via the Send Invoice UI)(processing block 616). Then, processing logic ensures that the items inthe invoice are still combinable (i.e., satisfy the combinable criteria)(processing block 617), saves the invoice in the database and sends anemail to the buyer, including a link to a page displaying the invoice(processing block 618). FIG. 11 illustrates an exemplary UI (InvoiceSent to Buyer UI) that informs the seller that an email with a link tothe invoice was sent to the buyer.

In one embodiment, the seller may request to uncombine items included inthe saved order or invoice. FIG. 12 illustrates an exemplary UI(Uncombine Purchases UI) allowing the seller to request that the itemsfrom the order or invoice be uncombined.

Further, upon receiving a buyer's request to view the invoice (e.g., thebuyer's selection of the link to the invoice in the email) (processingblock 620), processing logic displays the seller's created invoice tothe buyer (processing block 622). FIG. 13 illustrates an exemplary UI(Pay Now for Multiple Items UI) that displays the content of the invoiceto the buyer and allows the buyer to pay for the entire order or foreach item individually.

FIG. 14 is a block diagram of an alternative embodiment of aseller-initiated process 1400 for generating invoices consolidatingmultiple items. Process 1400 will be described in conjunction withexemplary user interfaces illustrated in FIGS. 15-18. In one embodiment,processing logic of process 1400 resides in a payment service systemproviding payment services to multiple network-based marketplaces,including the marketplace 12 of FIG. 1.

Referring to FIG. 14, process 1400 begins with processing logicdisplaying items sold by a seller within a predefined time period(processing block 1402). FIG. 15 illustrates an exemplary UI (Post SaleManager UI) that presents items sold by a seller in the past 30 days anda set of filters allowing the seller to view different categories ofitems sold by the seller (e.g., all items, unpaid items, paid items,unpaid uninvoiced items, unpaid combinable items, unpaid invoiced items,etc.).

At processing block 1404, processing logic receives seller's request todisplay a specific category of items sold by the seller (e.g., using afilter provided by the Post Sale Manager UI). In response, processinglogic displays the items of the specified category. In the discussedembodiment, processing logic may display all unpaid items (processingblock 1406) or combinable items that satisfy combinable criteria(processing block 1408). The combinable criteria may require, forexample, that the combinable items include subsets of multiple unpaiditems that have a common seller and a common buyer.

Next, processing logic receives data identifying the seller's selectionof items for the invoice and a request to generate the invoice(processing block 1410). FIG. 16 illustrates an exemplary UI (InvoiceManager UI) that presents unpaid items sold by the seller, allows theseller to select items for the invoice (e.g., one or more subsets ofcombinable items and/or individual items) and to send a request tocreate the invoice. The seller may request to invoice a single buyer fordifferent items or multiple buyers for different items.

Further, processing logic ensures that the selected items are stillunpaid, creates the invoice, and sends the invoice to one or more buyersupon a seller request to send the invoice (processing block 1416). FIG.17 illustrates an exemplary UI that presents the invoice to the sellerand allows the seller to specify charges for each subset of combinableitems or each individual transaction and to issue a request to send theinvoice to one or more buyers. If the invoice is sent to multiplebuyers, each buyer can only view an invoice portion that is relevant tothis buyer.

At processing block 1418, processing logic receives the buyer's requestto view the invoice (e.g., upon the buyer's selection of an invoice linkin an email sent to the buyer). In response, processing logic displaysthe invoice to the buyer (processing block 1420). FIGS. 18A and 18Billustrate exemplary UIs (Payment Details UI) that present the invoiceto the buyer.

At processing block 1422, processing logic receives the buyer's requestto pay for the items (e.g., via a pay button on the Payment Details UIof FIG. 18B) and processes the payment.

FIG. 19 is a block diagram of one embodiment of a buyer-initiatedprocess 1900 for generating invoices consolidating multiple items. Theprocess may be performed by processing logic, which may comprisehardware, software, or a combination of both. In one embodiment,processing logic resides in a payment server (e.g., one of theapplication servers 28 of FIG. 1). Process 1900 will be described inconjunction with exemplary user interfaces illustrated in FIGS. 20-23.

Referring to FIG. 19, process 1900 begins with processing logicdisplaying items purchased by a buyer within a certain time period(e.g., as specified by the buyer) with each combinable item having acombinability indicator (e.g., a designated icon) (processing block1902). FIG. 20 illustrates an exemplary UI (Items I've Won UI) thatpresents each combinable item with an icon and allows a buyer to selectan icon of a specific item to view the items combinable with thespecific item.

At processing block 1904, processing logic receives the buyer's requestto view a list of combinable items. In one embodiment, processing logicreceives the buyer's request to view a list of combinable items when thebuyer selects a combinability indicator of a specific item purchasedfrom a seller.

In response, processing logic displays the combinable items purchasedfrom the seller, receives the buyer's input identifying items to becombined into a single order (processing block 1906) and calculatescharges for the combined items. In one embodiment, processing logiccalculates charges for the items based on rules specified by the selleror standard rules maintained within the marketplace. FIG. 21 illustratesan exemplary UIs (Combine Purchases UI) that allows the buyer to checkitems to be combined in the invoice, displays charges (shipping andhandling charges, shipping insurance, and sales tax) for the combineditems, and allows the buyer to issue a request to pay for the items.

Next, processing logic receives the buyer's request to pay for thecombined items (processing block 1908), ensures that the items are stillcombinable (i.e., satisfy the combinable criteria) (processing block613), creates an order including the combined items, and saves the orderin the database.

One or more items from the order may no longer satisfy the combinablecriteria. Then, processing logic informs the buyer and offers the buyerto pay for the items individually, or removes the items that no longersatisfy the combinable criteria from the order and asks the buyer toreview the remaining items. FIG. 22 illustrates an exemplary UIdisplaying a message informing the seller that one or more items fromthe order are no longer combinable.

Further, processing logic asks the buyer to review order information tobe sent to the seller (processing block 1912), and, upon receiving anapproval of the order information from the buyer (processing block1914), sends the order information to the seller (processing block1916). FIG. 23A illustrates an exemplary UI (Send Information to SellerUI) displaying the order information and asking the buyer to confirmthat the order information is correct.

Afterwards, processing logic instructs the buyer to pay for the order(processing block 1918). FIG. 23B illustrates an exemplary UI (SendPayment to Seller UI) displaying payment information and asking thebuyer to make the payment.

In one embodiment, the buyer may request an invoice total from a sellerprior to confirming the combination of items or verifying thecorrectness of information to be sent to the seller. FIG. 24 illustratesan exemplary UI (Request Total from Seller UI) displaying the combineditems and asking the buyer to verify his or her shipping address toallow the seller to calculate charges for this order.

In one embodiment, a buyer or a seller can request the payment status ofan order. FIGS. 25A and 25B illustrate exemplary UIs (Buyer's PaymentStatus UI and Seller's Payment Status UI) displaying the orderinformation and the payment status of the order for a buyer and sellerrespectively.

In one embodiment, a seller can review a list of buyers with combinableitems purchased from the seller using a selling manager tool thatassists the seller in operations within the marketplace. FIG. 26Aillustrates an exemplary UI (Selling Manager Summary UI) including alink to a list of buyers with combinable items purchased from theseller. FIGS. 26B and 26C illustrate exemplary UIs (Selling Manager SoldListings UIs) displaying orders containing multiple transactions.

In one embodiment, a seller and a buyer may leave feedback for theentire order. Alternatively, they may leave feedback for eachtransaction within the order individually. FIG. 27 illustrates anexemplary UI (Selling Manager Leave Feedback UI) allowing the seller toleave feedback for the entire order.

In one embodiment, a shipping label and an invoice slip areautomatically created for an order and can be printed by a seller forthe package containing the order. FIG. 28 illustrates an exemplaryshipping label and invoice combination created for an order.

Charge Rules for Combined Transactions

A seller may specify charge rules for combined transactions that will beapplied to all subsequent combined purchases from this seller. In oneembodiment, a seller is allowed to specify discount rules for chargesassociated with combined transactions, thus encouraging buyers to buymore items from the seller.

FIGS. 29A-29B and 30A-30C are block diagrams of several embodiments of aprocess for defining rules for charges associated with combinedtransactions. The process may be performed by processing logic, whichmay comprise hardware, software, or a combination of both. In oneembodiment, processing logic resides in a payment server (e.g., one ofthe application servers 28 of FIG. 1).

Referring to FIG. 29A, process 2900 begins with processing logicreceiving data indicating a willingness of a first user to have combinedtransactions on invoices issued by the first user (processing block2902). In one embodiment, this data is received via a user interfacesoliciting input from the first user with respect to invoicesconsolidating multiple transactions.

At processing block 2904, processing logic defines a set of rules forcalculating charges for transactions combined on the invoices issued bythe first user. In one embodiment, the set of rules pertain to shippingand handling rates and shipping insurance rates. In one embodiment, theset of rules is defined based on input provided by the first user viauser interfaces presented by processing logic.

At processing block 2906, processing logic stores the set of rulesassociated with the first user in a database for subsequent use withinvoices issued by the first user. In one embodiment, the set of rulesdefined based on user input provided via UIs associated with amarketplace site can only be used with items purchased via thismarketplace site.

Referring to FIG. 29B, process 2900 will be described in conjunctionwith exemplary user interfaces illustrated in FIGS. 31A-31F.

Process 2950 begins with processing logic presenting a Login toPreferences UI to a seller (processing block 2952). FIG. 31A illustratesan exemplary Login to Preferences UI.

At processing block 2954, processing logic presents options forcombining transactions to the seller. FIG. 31B illustrates an exemplaryCombine Purchases Preference UI.

If processing logic receives data indicating that the seller does notallow combined transactions (processing block 2956), processing logicdisables combine purchases UIs (processing block 2958) and the displayof shipping discount messages on UIs presented to users of themarketplace (processing block 2960).

If processing logic receives data indicating that the seller allowscombined transactions with manual shipping discounts (processing block2962), processing logic enables combine purchases UIs and the display ofmessages encouraging multiple purchases from the seller, and solicitsthe seller's input of insurance rate options (processing block 2970).FIG. 31D illustrates an exemplary UI displaying the message “See MoreGreat Buys from this seller” for a seller who selected an option ofcombined transactions with manual shipping discounts.

If processing logic receives data indicating that the seller allowscombined transactions with automated shipping discounts (processingblock 2962), processing logic enables combine purchases UIs, solicitsthe seller's input of shipping discount rules for combined purchases(processing block 2966), solicits the seller's input of the date rangewithin which combined purchases are allowed (processing block 2968), andsolicits the seller's input of insurance rate options (processing block2970). Processing logic also enables the display of messages advertisingshipping discounts for combined purchases from the seller. FIGS. 31C,31E and 31F illustrate exemplary UIs displaying shipping discountmessages that vary depending on discount rules specified by the seller.

Referring to FIG. 30A, process 3000 begins with processing logicdetecting a seller preference for automated shipping discount rules forcombined transactions (processing block 3002) and presenting the sellerwith shipping rate rule options (processing block 3004). In thedescribed embodiment, the shipping rate rule options include a flat raterule option and an actual rate rule option. However, other embodimentsmay use additional and/or different rule options without loss ofgenerality.

If processing logic receives data indicating the seller's selection ofthe flat rate option (processing block 3008), processing logic presentsflat rate shipping charge options (processing block 3010) and flat rateinsurance options to the seller (processing block 3012), and receivesand stores shipping and insurance preferences of the seller in thedatabase (processing block 3020).

If processing logic receives data indicating the seller's selection ofan actual rate option (processing block 3014), processing logic presentsactual rate shipping charge options (processing block 3016) andinsurance options to the seller (processing block 3018), and receivesand stores shipping and insurance preferences of the seller in thedatabase (processing block 3020).

Referring to FIG. 30B, process 3020 begins with processing logicdetecting a seller's selection of a flat rate shipping discount(processing block 3022) and presenting a set of options for the flatrate shipping discount. Based on user input, processing logic mayreceive data identifying the seller's selection of an option to charge amaximum shipping rate for the first item and a fixed amount for eachadditional item (processing block 3024), data identifying the seller'sselection of an option to charge a maximum shipping rate for the firstitem and no charge for additional items (processing block 3026), or dataidentifying the seller's selection of an option to charge a maximumshipping rate for the first item and deduct a fixed amount from theshipping cost of each additional item (processing block 3026).

Next, in one embodiment, processing logic may receive the seller'sinstruction to deduct a certain percentage from the shipping cost ofeach item in the order (processing block 3030). Alternatively,processing logic may receive the seller's instruction to refrain fromapplying a discount to an item with the highest shipping cost(processing block 3032).

Once processing logic defines shipping rate rules, it begins definingshipping insurance rules. Specifically, processing logic displays a setof options for a flat rate shipping insurance (processing block 3034).These options may include, for example, an insurance not offered option,an optional insurance option, a required insurance option, and aninsurance included in shipping and handling option.

If processing logic receives data indicating the seller's selection ofan optional insurance option or a required insurance option (processingblock 3036), processing logic allows the seller to specify fixedinsurance amounts for different price ranges (processing block 3038),and saves the shipping and insurance rules in the database (processingblock 3040).

If processing logic receives data indicating the seller's selection ofan insurance not offered option or an insurance included in shipping andhandling option, processing logic proceeds directly to processing block3040.

FIG. 32A illustrates an exemplary UI (Combine Purchases Preference UI)displaying options for flat rate shipping and insurance discounts.

Referring to FIG. 30C, process 3050 begins with processing logicdetecting a seller's selection of an actual rate shipping discount(processing block 3052) and presenting a set of options for the actualrate shipping discount. Based on user input, processing logic mayreceive data identifying the seller's selection of an option to chargean actual shipping cost (based on the weight of the items in the order)and full package and handling fee (processing block 3054), dataidentifying the seller's selection of an option to charge an actualshipping cost and no package and handling fee (processing block 3056),data identifying the seller's selection of an option to charge an actualshipping cost and a fixed amount for package and handling fee for theentire order (processing block 3058), or data identifying the seller'sselection of an option to charge, for each item, an actual shipping costminus a fixed package and handling discount (processing block 3060).

Once processing logic defines shipping rate rules, it begins definingshipping insurance rules. Specifically, processing logic displays a setof options for an actual rate shipping insurance. These options mayinclude, for example, an insurance not offered option, an optionalinsurance option, a required insurance option, and an insurance includedin shipping and handling option. Processing logic then detects theseller's selection of an insurance option (processing block 3062), andsaves the shipping and insurance rules in the database (processing block3040).

FIG. 32B illustrates an exemplary UI (Combine Purchases Preference UI)displaying options for actual rate shipping discounts.

In one embodiment, the charge rules for combined purchases can bemodified by a seller. FIG. 33A illustrates an exemplary UI (CombinedPurchases Preferences Changes UI) confirming changes to the chargerules.

In one embodiment, the date of modification is saved, and the seller orhis trading partner can request to review a history of rulemodifications. In addition, once the rules are modified, a message maybe displayed to the seller's trading partners, indicating such amodification. FIG. 33B illustrates an exemplary UI (Combined PurchasesUI) displaying a shipping discount modification warning.

In one embodiment, a seller can modify charge rules or specify newcharge rules for combined purchases when describing a new item to beoffered within the network-based marketplace. FIG. 34 illustrates anexemplary UI (Sell Your Item UI) including a link to a CombinedPurchases Preference UI where the charge rules can be specified.

FIGS. 35 and 37 are block diagrams of several embodiments of a processfor calculating charges for invoices with combined transactions usingpredefined charge rules. The process may be performed by processinglogic, which may comprise hardware, software, or a combination of both.In one embodiment, processing logic resides in a payment server (e.g.,one of the application servers 28 of FIG. 1).

Referring to FIG. 35, process 3500 begins with processing logicfacilitating a combination of transactions on a single invoice to beissued by a first party (processing block 3502). In one embodiment, thecombination of transactions is facilitated via an order creation processdescribed in more details above.

At processing block 3504, processing logic identifies a rule, specifiedby the first user, for an automated calculation of charges in connectionwith invoices issued by the first party. The charges may includeshipping charges, package and handling charges, insurance charges, etc.In one embodiment, the rule is identified by retrieving the ruleassociated with the first party from the database.

At processing block 3506, processing logic determines that thetransactions being combined satisfy rule application criteria. The ruleapplication criteria may require, for example, that each transactionhave shipping details specified, all transactions have the same type ofshipping cost (e.g., flat rate or actual rate), all transactions withthe same type of shipping cost share the same shipping method, etc.

At processing block 3508, processing logic dynamically invokes the ruleto calculate charges for the transactions included in the order, anddisplays the calculated charges with the order. In one embodiment,processing logic also computes a difference between the chargescalculated using a discount provided by the charge rule and chargescalculated without a discount, and displays the difference to the buyer.FIG. 36 illustrates an exemplary UI (Combine Purchases UI) thatspecifies how much the buyer can save on shipping by combiningtransactions into a single order.

Referring to FIGS. 37A-37C, process 3700 begins with processing logicreceiving a call to calculate shipping costs for multi-transaction order(processing block 3702), determining whether each transaction meets ruleapplication criteria (processing block 3704), and, if so, retrievingcharge rules applicable to the multi-transaction order. The ruleapplication criteria may require, for example, that each transactionhave shipping details specified, all transactions have the same type ofshipping cost (e.g., flat rate or actual rate), all transactions withthe actual shipping rate share the same shipping method if using acombined weight measure, etc.

Next, processing logic determines whether the charge rules are based onactual rate (processing block 3706). If so, processing logic determineswhether the rules are based on combined weight or individual weight(processing block 3708). If the rules are based on combined weight,processing logic determines whether the combined weight exceeds carrierlimit (processing block 3712). If not, processing logic proceeds toprocessing block 3714.

If the combined weight exceeds the carrier limit, or the rules are basedon individual weight, processing logic calculates actual shipping ratebased on weight of individual items (processing block 3714) and proceedsto processing block 3714.

At processing block 3714, processing logic determines the seller'shandling fee preferences. If the rules specify full packaging andhandling fee (processing block 3716) and the rules are based on combinedweight (processing block 3718), processing logic calculates combinedshipping costs by adding the actual rate based on total weight to thesum of handling fees of all items (processing block 3720).

If the rules specify full packaging and handling fee (processing block3716) and the rules are based on individual weight (processing block3718), processing logic calculates combined shipping costs by adding thesum of actual rates based on individual shipping rate per item to thesum of handling fees of all items (processing block 3722).

If the rules specify actual shipping cost only (processing block 3724),processing logic does not add any handling fee to the combined shippingcost (processing block 3726).

If the rules specify fixed packaging and handling fee (processing block3728) and the rules are based on combined weight (processing block3730), processing logic calculates combined shipping costs by adding theactual shipping rate based on total weight to the seller-specifiedhandling fee (processing block 3732).

If the rules specify fixed packaging and handling fee (processing block3728) and the rules are based on individual weight (processing block3730), processing logic calculates combined shipping costs by adding thesum of actual rates based on individual rate per item to theseller-specified handling fee (processing block 3734).

If the rules require that a fixed amount be deducted from a handling feeof each item (processing block 3736) and the rules are based on combinedweight (processing block 3738), processing logic calculates combinedshipping costs by computing, for each item, a difference between thehandling fee of this item and the fixed amount, calculating the sum ofall positive differences (differences that are equal to, or greaterthan, zero) and adding the calculated sum to the actual rate based ontotal weight (processing block 3740).

If the rules require that a fixed amount be deducted from a handling feeof each item (processing block 3736) and the rules are based onindividual weight (processing block 3738), processing logic calculatescombined shipping costs by computing, for each item, a differencebetween the handling fee of this item and the fixed amount, calculatingthe sum of all positive differences, and adding the calculated sum tothe sum of actual shipping rate based on individual weight per item(processing block 3740).

If the charge rules are based on flat rate (processing block 3706),processing logic determines user-specified flat rate preference(processing block 3748). If the flat rate preference requires that theshipping cost be based on the highest single item charge plus a fixedamount for each additional item (processing block 3750), processinglogic calculates the combined shipping cost by adding the highest singleitem charge and a fixed amount for each additional item (processingblock 3752).

If the flat rate preference requires that the shipping cost be based onthe highest single item charge plus a difference between the shippingcost and a fixed amount for each additional item (processing block3754), processing logic calculates the combined shipping cost bycomputing differences between the shipping cost of each item and thefixed amount, calculating the sum of all positive differences, andadding the sum of positive differences to the highest single itemshipping cost (processing block 3756).

If the flat rate preference requires free shipping for each additionalitem (processing block 3758), the combined shipping cost is equal to thehighest single item shipping charge (processing block 3760).

If the flat rate preference requires that the shipping cost be based onitem charge for each item minus a fixed percentage (processing block3762), processing logic calculates the combined shipping cost bycomputing differences between the shipping cost of each item and thefixed percentage and calculating the sum of all positive differences(processing block 3764).

Exemplary Computer System

FIG. 38 shows a diagrammatic representation of machine in the exemplaryform of a computer system 3800 within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed. In alternative embodiments, themachine operates as a standalone device or may be connected (e.g.,networked) to other machines. In a networked deployment, the machine mayoperate in the capacity of a server or a client machine in server-clientnetwork environment, or as a peer machine in a peer-to-peer (ordistributed) network environment. The machine may be a personal computer(PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant(PDA), a cellular telephone, a web appliance, a network router, switchor bridge, or any machine capable of executing a set of instructions(sequential or otherwise) that specify actions to be taken by thatmachine. Further, while only a single machine is illustrated, the term“machine” shall also be taken to include any collection of machines thatindividually or jointly execute a set (or multiple sets) of instructionsto perform any one or more of the methodologies discussed herein.

The exemplary computer system 3800 includes a processor 3802 (e.g., acentral processing unit (CPU) a graphics processing unit (GPU) or both),a main memory 3804 and a static memory 3806, which communicate with eachother via a bus 3808. The computer system 3800 may further include avideo display unit 3810 (e.g., a liquid crystal display (LCD) or acathode ray tube (CRT)). The computer system 3800 also includes analphanumeric input device 3812 (e.g., a keyboard), a cursor controldevice 3814 (e.g., a mouse), a disk drive unit 3816, a signal generationdevice 3818 (e.g., a speaker) and a network interface device 3820.

The disk drive unit 3816 includes a machine-readable medium 3822 onwhich is stored one or more sets of instructions (e.g., software 3824)embodying any one or more of the methodologies or functions describedherein. The software 3824 may also reside, completely or at leastpartially, within the main memory 3804 and/or within the processor 3802during execution thereof by the computer system 3800, the main memory3804 and the processor 3802 also constituting machine-readable media.

The software 3824 may further be transmitted or received over a network3826 via the network interface device 3820.

While the machine-readable medium 3892 is shown in an exemplaryembodiment to be a single medium, the term “machine-readable medium”should be taken to include a single medium or multiple media (e.g., acentralized or distributed database, and/or associated caches andservers) that store the one or more sets of instructions. The term“machine-readable medium” shall also be taken to include any medium thatis capable of storing, encoding or carrying a set of instructions forexecution by the machine and that cause the machine to perform any oneor more of the methodologies of the present invention. The term“machine-readable medium” shall accordingly be taken to include, but notbe limited to, solid-state memories, optical and magnetic media, andcarrier wave signals.

Thus, methods and systems to facilitate generation of invoices combiningmultiple transactions established utilizing a multi-seller network-basedmarketplace have been described. Although the present invention has beendescribed with reference to specific exemplary embodiments, it will beevident that various modifications and changes may be made to theseembodiments without departing from the broader spirit and scope of theinvention. Accordingly, the specification and drawings are to beregarded in an illustrative rather than a restrictive sense.

1. A computerized method to facilitate invoicing for transactionsestablished using a network-based transaction system, the methodincluding: supporting, by a server machine, establishment oftransactions between a plurality of entities in the network-basedtransaction system; identifying, with the server machine, as part of aninvoice generation process, a plurality of transactions to which a firstentity is a party; identifying, with the server machine, first andsecond transactions from the plurality of transactions that satisfycombinable criteria; and generating, with the server machine, an invoicefor at least the first and second transactions that satisfy thecombinable criteria.
 2. The computerized method of claim 1, wherein thefirst entity is a seller, and the identification of the plurality oftransactions is performed responsive to an initiation of the invoicegeneration process by a second entity.
 3. The computerized method ofclaim 1, wherein the first entity is a buyer, and the identification ofthe plurality of transactions is performed as part of a payment process.4. The computerized method of claim 3, wherein: the identification ofthe plurality of transactions is performed responsive to the buyerinitiating the payment process in connection with the first transaction;and the method includes identifying a third transaction involving thebuyer that is combinable with one or more of the first transaction andthe second transaction based on the combinable criteria.
 5. Thecomputerized method of claim 1, wherein the identification of the firstand second transactions includes determining that a seller agreed tocombinability of transactions involving the seller.
 6. The computerizedmethod of claim 5, wherein the determining includes retrievingseller-defined preferences with respect to the combinability oftransactions involving the seller.
 7. The computerized method of claim1, wherein the identification of the first and second transactionsincludes identifying each of the first and second transactions as beingbetween a common buyer and a common seller.
 8. The computerized methodof claim 1, wherein the identification of the first and secondtransactions includes identifying each of the first and secondtransactions as having been established in terms of a common currency.9. The computerized method of claim 1, wherein the supporting of theestablishment of the first and second transactions between the pluralityof entities is performed at a plurality of network-based transactionsystems.
 10. The computerized method of claim 9, wherein the pluralityof network-based transaction systems includes a plurality ofgeographically customized network-based transaction systems.
 11. Thecomputerized method of claim 1, wherein the identification of the firstand second transactions to which the first entity is a party includesidentifying the first and second transactions as having been concludedwithin a predetermined time period.
 12. The computerized method of claim1, further comprising: presenting the first and second transactions tothe first entity as being combinable; and prompting the first entity forconfirmation regarding an inclusion of the first and second transactionsin the invoice.
 13. The computerized method of claim 1, wherein theidentification of the first and second transactions comprises:presenting to the first entity a list of unpaid transactions selectedfrom the first and second transactions; and receiving data identifying aselection by the first entity of one or more transactions from the listfor the invoice.
 14. The computerized method of claim 13, wherein thelist of unpaid transactions comprises one or more subsets of combinabletransactions, each of the one or more subsets being associated with thefirst entity and a buyer.
 15. The computerized method of claim 14,wherein the invoice includes one or more subsets of combinabletransactions and one or more independent transactions.
 16. Thecomputerized method of claim 1, wherein the network-based transactionsystem comprises a network-based marketplace.
 17. The computerizedmethod of claim 1, wherein the identifying the first and secondtransactions comprises displaying on a client machine the first andsecond transactions with an indicator of combinability.
 18. Thecomputerized method of claim 17, wherein the indicator of combinabilityis an icon.
 19. The computerized method of claim 1, wherein theidentifying the first and second transactions comprises providing, bythe server machine, a filter for combinable transactions; and displayingon a client machine the first and second transactions in response to aselection of the filter for combinable transactions by the first entity.20. The computerized method of claim 1, comprising providing a discountto the first entity when the first entity agrees to combine transactionsthat satisfy combinable criteria.
 21. The computerized method of claim1, comprising providing to the first entity an indication of savingsresulting from combining the transactions.
 22. A system to facilitateinvoicing for transactions established using a network-based transactionsystem, the system including: a server to support establishment oftransactions between a plurality of entities; and a server to identify,as part of an invoice generation process, a plurality of transactions towhich a first entity is a party, to identify first and secondtransactions from the plurality of transactions that satisfy combinablecriteria, and to generate an invoice for at least one of the first andsecond transactions that satisfy the combinable criteria.
 23. The systemof claim 22, wherein the identification of the first and secondtransactions includes determining whether a seller agreed tocombinability of transactions involving the seller.
 24. The system ofclaim 22, wherein the identification of the first and secondtransactions includes identifying each of the first and secondtransactions as being between a common buyer and a common seller. 25.The system of claim 22, comprising: a server to present the first andsecond transactions to the first entity as being combinable; and aserver to prompt the first entity for confirmation regarding aninclusion of the first and second transactions in the invoice.
 26. Thesystem of claim 22, wherein the network-based transaction systemcomprises a network-based marketplace.
 27. The system of claim 22,wherein the identification of the first and second transactionscomprises providing, by a server, a filter for combinable transactions;and displaying on a client machine the first and second transactions inresponse to a selection of the filter for combinable transactions by thefirst entity.
 28. The system of claim 22, comprising a server to providea discount to the first entity when the first entity agrees to combinetransactions that satisfy combinable criteria.
 29. The system of claim22, comprising a server to provide to the first entity an indication ofsavings resulting from combining the transactions.
 30. A tangiblemachine-readable storage medium storing a set of instructions that, whenexecuted by a machine, cause the machine to perform a method tofacilitate invoicing for transactions established utilizing anetwork-based transaction system, the method including: supportingestablishment of transactions between a plurality of entities in thenetwork-based transaction system; identifying, as part of an invoicegeneration process, a plurality of transactions to which a first entityis a party; identifying first and second transactions that satisfycombinable criteria; and generating an invoice for at least the firstand second transactions that satisfy the combinable criteria.
 31. Themachine-readable medium of claim 30, wherein the identification of thefirst and second transactions includes determining whether a selleragreed to combinability of transactions involving the seller.
 32. Themachine-readable medium of claim 30, wherein the identification of thefirst and second transactions includes identifying each of the first andsecond transactions as being between a common buyer and a common seller.33. The machine readable medium of claim 30, comprising instructionsfor: presenting the first and second transactions to the first entity asbeing combinable; and prompting the first entity for confirmationregarding an inclusion of the first and second transactions in theinvoice.
 34. The machine readable medium of claim 30, wherein thenetwork-based transaction system comprises a network-based marketplace.35. The machine readable medium of claim 30, wherein the identifying thefirst and second transactions comprises providing, by the servermachine, a filter for combinable transactions; and displaying on aclient machine the first and second transactions in response to aselection of the filter for combinable transactions by the first entity.36. The machine readable medium of claim 30, comprising instructions forproviding a discount to the first entity when the first entity agrees tocombine transactions that satisfy combinable criteria.
 37. The machinereadable medium of claim 30, comprising instructions for providing tothe first entity an indication of savings resulting from combining thetransactions.